1. Field
The present disclosure relates generally to NAT, and more specifically to Full Cone NAT and address-restricted cone NAT performed on a Linux system.
2. Background
When IP addressing was originally created, the small size of the Internet at the time, led people to believe that the number of IP addresses would be more than enough to handle any need. As networks of home and business computers and other devices exploded, this view began to change. Realizing that there were not enough IP addresses to sustain this growth, network address translation, or NAT, was developed as a network protocol enabling a router or other routing device (a “NAT device”) to act as a translator (think of a telephone switchboard operator) between multiple devices on a private network and devices on the public Internet, and in this way enable multiple devices on a private network to share a single, and increasingly scarce, public IP address.
In particular, a NAT device changes or translates a source IP address in a header of outgoing packets from devices in the private network so that the packets appear to be coming from the NAT device. In other words, the source IP address of outgoing packets is changed or translated from the private IP address of the originating device to the public IP address of the NAT device. The NAT device also creates a mapping of this translation so that it can guide incoming (responding) traffic to the correct device on the private network. Responding devices on the public Internet believe that they are receiving packets from the NAT device, and therefore respond by sending packets to the NAT's public IP address. The NAT device then uses the stored mapping to determine which device on the private network to forward incoming traffic to, and further changes a destination IP address in a header of incoming packets to that of the device on the private network that the packets are being forwarded to. In this way, both sending and receiving devices are unaware of the NAT's existence in the communication path.
While NAT was originally designed to enable multiple devices on a private network to share a single public IP address, more recent applications have included firewall-type purposes such as the masking of private IP addresses and filtering of incoming traffic.
Such applications are carried out via four different types of NAT: Full Cone; address restricted cone; port restricted cone; and symmetric. Systems using a LINUX kernel can perform port-restricted cone and symmetric NAT as these are supported by the LINUX kernel. However, the LINUX kernel does not support Full Cone and address restricted cone NAT. One workaround is use of the “NATTYPE module”, which can be run within the LINUX kernel. The NATTYPE module adds functions to the default Linux kernel functions that further enable the Linux kernel to perform Full Cone and address restricted cone NAT translation.
While this workaround is typically effective, problems arise when used in combination with a hardware accelerator. Hardware accelerators are hardware components (e.g., integrated circuits) that are used to increase performance of computing operations where specially designed hardware can more quickly or more efficiently perform processes than a similar software component running on a general-purpose CPU. Firewall and NAT operations in software consume a large portion of processing resources (e.g., million instructions per second or MIPS) and thus to enable high data throughput, it is desirable to distribute some or all firewall and NAT operations to a hardware accelerator. This enables software components such as the kernel to perform other processing duties in parallel with the firewall and NAT operations. The problem with using hardware acceleration in the NAT context, is that if Full Cone and address restricted cone NAT are desired, and therefore the NATTYPE module is used to overcome the kernel's default inability to perform these types of NAT's, then use of hardware acceleration causes entries created by the NATTYPE module to time out. This results in dropping of packets from known connections.
In particular, the LINUX kernel typically maps private to public IP addresses and ports for incoming and outgoing packets (depending on the NAT type). These mappings are stored in conntrack entries of kernel memory. These entries include timeout values that decrement unless periodically refreshed. Once a conntrack entry is created for a new connection, subsequent packets pass through the hardware accelerator rather than the kernel, and thus the timeout values in the conntrack entries in the kernel decrement. A userspace controller of the hardware accelerator monitors packet translation in the hardware accelerator and periodically updates the conntrack entries in the kernel based on this monitoring.
Similarly, when the NATTYPE module is invoked, the kernel creates conntrack entries and NATTYPE entries for new connections, and both types of entries have timeout values that need to be periodically refreshed. Again, subsequent packets from a known connection pass solely through the hardware accelerator. The libnetfilter_conntrack is a userspace library which provides an interface to alter the conntrack entries through netlink sockets. The libnetfilter_conntrack includes a mechanism to update/alter conntrack entries but does not include a mechanism for updating/altering the NATTYPE entries. The hardware accelerator controller refreshes the conntrack entries, using this mechanism, but since it is unable to update the NATTYPE entries, they eventually timeout. When they timeout, subsequent incoming packets are no longer recognized as coming from a known external source and are thus dropped.